home *** CD-ROM | disk | FTP | other *** search
- draft A Model for Enabled Mail (EM) May 1993
-
-
- A Model for Enabled Mail (EM)
-
- Thu May 6 22:50:18 1993
-
-
- Marshall T. Rose
- Dover Beach Consulting, Inc.
- mrose@dbc.mtview.ca.us
-
-
- Nathaniel Borenstein
- Bellcore
- nsb@bellcore.com
-
-
-
-
-
- Status of this Memo
-
- This document is a working draft. Do not cite, copy, or
- circulate.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 1]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- 1. Introduction
-
- This memo defines an enhancement, termed Enabled Mail (EM), to
- the message handling model used in computer-communications
- systems. The memo begins by describing the traditional model
- for message handling. Next, an enhancement to the model is
- suggested which augments the final delivery process with
- additional services. Finally, specific technology choices are
- recommended for experimental purposes within the Internet
- community.
-
-
- 2. The Traditional Model for Message Handling
-
- In 1979, the International Federation for Information
- Processing (IFIP), a pre-standards organization, developed a
- model for message handling. This model was eventually adopted
- and expanded by the the International Telephone and Telegraph
- Consultative Committee (CCITT), which developed the X.400
- series of recommendations.
-
- Pictorially, the message handling model is organized thusly:
-
- +----+ messaging +----+
- | UA | - - - - - - - - - - - - - - - -> | UA |
- +----+ +----+
- | /|\
- | |
- | posting | delivery
- |--------- |----------
- | |
- | |
- +---|---------------------------------------------+
- | | MTS | |
- | \|/ | |
- | +-----+ +-----+ +-----+ |
- | | MTA | --> | MTA | --> ... --> ... --> | MTA | |
- | +-----+ +-----+ relaying +-----+ |
- | |
- +-------------------------------------------------+
-
- As shown here, electronic mail messages are transported by a
- "message transfer system" (MTS), which is composed of one or
- more "message transfer agents" (MTAs). The message transfer
- system is distributed in nature, and not under a single
-
-
-
-
-
- [Page 2]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- administrative entity; in contrast, a collection of message
- transfer agents are usually controlled by a single
- administrative entity. At the edges of the system, a "user
- agent" (UA) acts on behalf of a user to interact with the
- local message transfer agent.
-
- From the perspective of the message transfer system, the
- electronic mail message being sent is called the "content",
- and all delivery information associated with the message is
- called the "envelope". In theory, the message transfer system
- is ignorant of the structure of the content it transports; the
- user agents bilaterally agree as to what this structure is.
- Although there are no strict requirements as to the structure,
- there are usually two components in each electronic mail
- message: control information (often called the "headers"), and
- data information (often called the "body"). A convenient way
- of thinking about all these terms is:
-
- o the envelope is meaningful to the message transfer
- agents;
-
- o the headers are meaningful to the user agents; and,
-
- o the body is meaningful to the users (which may be people
- or programs).
-
- When an electronic mail message is sent from one user to
- another, the following activities occur: the originator
- indicates to the user agent the address of the recipient; the
- user agent places the destination address and the sender's
- address into the envelope and then posts the message through a
- "posting slot" to a message transfer agent, which involves a
- posting protocol in which the validity of those addresses and
- the syntax of the electronic mail message are considered.
- Upon successful completion of the submission protocol, the
- message transfer agent accepts responsibility either to
- deliver the electronic mail message, or, if so requested and
- if delivery fails, to inform the originator of the failure by
- generating an "error report".
-
- After accepting responsibility to deliver the electronic mail
- message, a message transfer agent must decide if it can
- deliver the message directly to the recipient; if so, it
- delivers the electronic mail message through a "delivery slot"
- to the recipient's user agent, using a delivery protocol. If
-
-
-
-
-
- [Page 3]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- not, it contacts an adjacent message transfer agent, which is
- closer to the recipient, and negotiates transfer of the
- electronic mail message. This process repeats until some
- message transfer agent is able to deliver the electronic mail
- message, or some message transfer agent determines that the
- message is undeliverable.
-
- To summarize, there are three general protocols involved in
- the model:
-
- o a "messaging" protocol used between two user agents;
-
- o a "relaying" protocol used between two message transfer
- agents; and,
-
- o "submission/delivery" protocol used between a message
- transfer agent and a user agent.
-
- In the Internet community, RFC 822 [1] and MIME [2,3] define
- the messaging protocol, whilst SMTP [4] defines the relaying
- protocol. Submission and delivery protocols are considered a
- local matter, although it is common to use SMTP for submission
- and POP3 [5] for delivery.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 4]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- 3. Enhancing the Model with Enabled Mail
-
- The Enabled Mail (EM) enhancement to the model occurs during
- and after delivery processing. Specifically, the model is
- enhanced by viewing the delivery process as consisting of
- three distinct phases:
-
- o "delivery-time", which occurs immediately before the
- message crosses the delivery slot;
-
- o "receipt-time", which occurs immediately after the
- message crosses the delivery slot; and,
-
- o "activation-time", which occurs whenever the recipient
- processes the message.
-
- In each of these phases, a user-defined program is evaluated,
- each with a different execution environment.
-
-
- 3.1. The Delivery-Time EM Phase
-
- Immediately before the message crosses the delivery-slot, a
- program defined by the originator, if present in the message,
- is evaluated by the message transfer agent performing final
- delivery. Such a program has access to the message being
- delivered and its envelope, can engage in a negotiation
- process with the recipient's user agent, but has no
- interactive access to the recipient.
-
- An example of a program evaluated during Delivery-Time EM
- would be something which automatically sends a delivery
- acknowledgement to the originator.
-
- Note that any program transported through the message transfer
- system must be evaluated in a "execution-safe" environment,
- one in which arbitrary programs, written by an unknown or
- hostile party, can be evaluated without fear of system
- compromise.
-
-
- 3.2. The Receipt-Time EM Phase
-
- Immediately after the message crosses the delivery slot, a
- program defined by the recipient, if present in the
-
-
-
-
-
- [Page 5]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- recipient's local configuration, is evaluated by the
- recipient's UA. Such a program has access to the message
- being delivered and its envelope, but has no interactive
- access to the recipient.
-
- An example of a program evaluated during Receipt-Time EM would
- be something which automatically files a message into one or
- more folders, based on originator and subject.
-
- Note that the program evaluated during Receipt-Time EM is
- provided by the recipient, and, if properly coded, should be
- safe for execution in the recipient's environment. This is
- often a necessity, as many receipt-time EM activities are
- likely to require the recipient's privileges when accessing
- system resources.
-
-
- 3.3. The Activation-Time EM Phase
-
- Whenever the recipient processes the message, e.g., for
- rendering, a program defined by the originator, if present, is
- evaluated by the recipient's UA. Such a program does not have
- access to the message or its envelope, but may have
- interactive access to the recipient.
-
- An example of a program evaluated during Activation-Time EM
- would be something which queries the user for some information
- and then sends the response back to the originator.
-
- Note that any program transported through the message transfer
- system must be evaluated in a "execution-safe" environment,
- one in which arbitrary programs, written by an unknown or
- hostile party, can be evaluated without fear of system
- compromise.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 6]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- 4. An Experiment in EM for the Internet Community
-
- In order to foster interoperability, this memo recommends the
- following EM technology choices for the Internet community.
-
-
- 4.1. Delivery-Time EM
-
- If during final delivery, the message transfer agent
- determines that the message is of content-type
- "multipart/enabled-mail" [6], then the Delivery-Time EM phase
- is entered. When this phase terminates, the entire message is
- delivered to the recipient's user agent.
-
- This content-type contains two parts, the first is an
- arbitrary content-type, and the second is of content-type
- "application/safe-tcl" with parameter "evaluation-
- time=delivery". Safe-Tcl [6] is a subset of the Tcl [7]
- environment which is believed to be safe for evaluating
- programs written by an unknown or hostile party.
-
-
- 4.2. Receipt-Time EM
-
- If the recipient's user agent has been configured to evaluate
- a Tcl script when messages are received, then the Receipt-Time
- EM phase is entered whenever final delivery occurs for that
- recipient.
-
- The Tcl script will be evaluated with the recipient's
- privileges. In addition to the standard Tcl environment, the
- Tcl procedures and variables defined in Sections 4.2, 4.3, and
- 4.4 of [6] are available.
-
- Note that no recipient-interaction is possible during
- Receipt-Time EM, as such any attempts at terminal-I/O will
- always generate an error during Receipt-Time EM.
-
-
- 4.3. Activation-Time EM
-
- The Activation-Time EM phase occurs whenever the recipient
- renders a MIME entity containing the "application/safe-tcl"
- content-type and having a parameter value of "evaluation-
- time=activation".
-
-
-
-
-
- [Page 7]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- 4.4. Configuration Information
-
- A user agent participating in EM provides configuration
- information to the local message transfer agent. This
- information includes, but is not limited to:
-
- (1) customization information for Safe-Tcl's getconfigdata
- primitive;
-
- (2) size and time limits for the Delivery-Time, Receipt-Time,
- and Activation-Time EM phases;
-
- (3) a Tcl script to be evaulated during Receipt-Time EM; and,
-
- (4) a collection of user-defined Tcl scripts, for use during
- EM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 8]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- 5. Security Considerations
-
- Delivery-Time EM and Activation-Time EM should occur in
- "execution-safe" environments. Any technology choice used for
- either of these phases should be the subject of intense
- scrutiny.
-
-
- 6. Acknowledgements
-
- Einar Stefferud of Network Management Associates suggested the
- names used to denote the three phases of EM.
-
-
- 7. Authors' Addresses
-
- Nathaniel S. Borenstein
- MRE 2D-296
- Bellcore
- 445 South Street
- Morristown, NJ 07962-1910
- US
-
- Phone: +1 201 829 4270
- Fax: +1 201 829 5963
- Email: nsb@bellcore.com
-
-
- Marshall T. Rose
- Dover Beach Consulting, Inc.
- 420 Whisman Court
- Mountain View, CA 94043-2186
- US
-
- Phone: +1 415 968 1052
- Fax: +1 415 968 2510
- Email: mrose@dbc.mtview.ca.us
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 9]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- 8. References
-
- [1] D.H. Crocker. Standard for the Format of ARPA Internet
- Text Messages. Request for Comments 822, (August, 1982).
-
- [2] N. Borenstein, N. Freed. MIME: Mechanisms for Specifying
- and Describing the Format of Internet Message Bodies.
- Request for Comments 1341, (June, 1992).
-
- [3] K. Moore. Representation of Non-ASCII Text in Internet
- Message Headers. Request for Comments 1342, (June,
- 1992).
-
- [4] J.B. Postel. Simple Mail Transfer Protocol. Request for
- Comments 821, (August, 1982).
-
- [5] M.T. Rose. Post Office Protocol: Version 3. Request for
- Comments 1225, (May, 1991).
-
- [6] N. Borenstein, M. Rose. MIME Extensions for Mail-Enabled
- Applications: application/Safe-Tcl and
- multipart/enabled-mail. Draft in preparation, (May,
- 1993).
-
- [7] J. Ousterhout. An Introduction to Tcl and Tk. Addison-
- Wesley, (to appear in 1993).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 10]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- Appendix A. Usage Example: Delivery-Time EM
-
- Here is a brief example of a program that might be evaluated
- during the Delivery-Time EM phase:
-
- Content-Type: application/safe-tcl; evaluation-time=delivery
-
- sndmsg $Tcl_originator "" \
- "Delivery Notification for $Tcl_recipient"
- [getheader message-id]
-
- This simply sends a message to the originator indicating that
- the incoming message crossed the delivery slot for the
- recipient.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 11]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- Appendix B. Usage Example: Receipt-Time EM
-
- Here is a brief example of a program that might be evaluated
- during the Receipt-Time EM phase:
-
- savemsg mailbox "mhbox/INCOMING"
-
- proc mboxP {header mboxes} {
- foreach addr [getaddrs [gethdr $header]] {
- set local [getaddrprop $addr local]
- foreach mbox mboxes {
- if {regexp -nocase $mbox $local} {
- return 1
- }
- }
- }
-
- return 0
- }
-
- set mboxlist [list "^mrose$" "^iesg$"]
- if {[mboxP To $mboxlist] || [mboxP cc $mboxlist]} {
- radiomail
- }
-
- savemsg mailbox
-
- First, the incoming message is appended to the user's mailbox
- named "mhbox/INCOMING". Next, a procedure, "mboxP" is
- defined. The variable "mboxlist" is set to an array
- containing two elements. Then a check is made to see if
- either the To field or the cc field contains an address having
- either element as its local-part. If so, the procedure
- "radiomail" is called. Finally, the incoming message is
- appended to the user's default mailbox.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 12]
-
-
-
-
-
- draft A Model for Enabled Mail (EM) May 1993
-
-
- Table of Contents
-
-
- 1 Introduction .......................................... 2
- 2 The Traditional Model for Message Handling ............ 2
- 3 Enhancing the Model with Enabled Mail ................. 5
- 3.1 The Delivery-Time EM Phase .......................... 5
- 3.2 The Receipt-Time EM Phase ........................... 5
- 3.3 The Activation-Time EM Phase ........................ 6
- 4 An Experiment in EM for the Internet Community ........ 7
- 4.1 Delivery-Time EM .................................... 7
- 4.2 Receipt-Time EM ..................................... 7
- 4.3 Activation-Time EM .................................. 7
- 4.4 Configuration Information ........................... 8
- 5 Security Considerations ............................... 9
- 6 Acknowledgements ...................................... 9
- 7 Authors' Addresses .................................... 9
- 8 References ............................................ 10
- A. Usage Example: Delivery-Time EM .................... 11
- B. Usage Example: Receipt-Time EM ..................... 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 13]
-
-
-
-